1. Field of the Invention
This invention relates to legacy systems, and particularly to a method for capturing and converting a legacy application into a Business Process Execution Language (BPEL) model supporting Service Oriented Architecture (SOA) capabilities.
2. Description of Background
A legacy system is an existing computer system or application program, which continues to be used because the user (typically an organization) does not want to replace or redesign the computer system or application program. Legacy systems are considered to be potentially problematic by many software engineers for several reasons. Some of these reasons include the fact that legacy systems often run on obsolete hardware, and spare parts for such computer systems becomes increasingly difficult to obtain. In addition, these computer systems are often hard to maintain, improve, and expand because there is a general lack of understanding of the system. Also, the designers of such computer systems may have left the organization, so there is no one left to explain how it works. Inadequate documentation or manuals getting lost can exacerbate such a lack of understanding of how the system works. Integration with newer systems may also be difficult because new software may use completely different technologies.
As a result, maintaining and upgrading legacy systems is one of the most difficult challenges many organizations face today. Constant technological change often weakens the business value of legacy systems, which have been developed over the years through huge investments. Organizations constantly struggle with the problem of modernizing these systems while keeping their functionality intact. Rewriting a legacy system from scratch can create a functionally equivalent information system based on modern software techniques and hardware. However, the high risk of failure associated with any large software project lessens the chances of success.
Nevertheless, Service Oriented Architecture (SOA) systems may provide for a solution. SOA provides a process, including choreographer capabilities, process modeling, and application generation capabilities. Put simply, a SOA is any well-bounded, defined, and repeatable business task that can be invoked in a standard manner. The scope of this task can range from very narrow to quite broad. Thus, it may be a simple, one-step task, such as setting a customer's billing address, or a more complex task involving several steps and a number of possible outcomes.
In SOA systems, services can be nested. That is, one service can call another to perform a subtask. Within a service, the outcome of one task can influence whether another task is called or not. For example, depending on the outcome of a credit check, different credit limits may be imposed, or, in the worst case, the account may not be set up at all. This type of integration of services and the linking of outcomes is called service orientation. It is precisely this service orientation that allows applications built in this style to be both flexible and integrated.
Therefore, an SOA is simply an Information Technology (IT) architectural style that supports service orientation, based on open standards. It enables the modeling, design, assembly, deployment, and management of flexible, integrated applications from reusable services that are independent of the applications and computing platforms on which they run, supported by a governance approach and best practices derived from experience.
In the alternative, an SOA may be thought of as a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is required. One goal of SOA is creating a worldwide mesh of collaborating services that are published and available for invocation on a Service Bus. Therefore, adopting SOA is essential to delivering the business agility and IT flexibility promised by Web Services.
However, SOA is captured in the form of business process resources. Business processes are described by using a Business Process Execution Language (BPEL) standard. In computing, BPEL is a business process language that is serialized in XML (Extensible markup language) and aims to enable programming in the large. The concepts of programming in the large and programming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes.
Programming in the large generally refers to the high-level state transition interactions of a process. BPEL refers to this concept as an Abstract Process. A BPEL Abstract Process represents a set of publicly observable behaviors in a standardized fashion. An Abstract Process includes information such as when to wait for messages, when to send messages, when to compensate for failed transactions, etc. Programming in the small, in contrast, deals with short-lived programmatic behavior, often executed as a single transaction and involving access to local logic and resources such as files, databases, etc. BPEL's development came out of the notion that programming in the large and programming in the small required different types of language. As a result, in addition to adopting a SOA, adopting a BPEL is also critical to delivering the business agility and IT flexibility promised by Web Services.
Consequently, in today's world, business agility is a requirement to subsist and IT systems are required to react rapidly. To change in a cost-efficient manner, integration must take place at the business process level in order to meet these goals. This level of integration is often referred to as Business Process Integration (BPI), and is the recommended integration approach when using SOA. Because business processes often span multiple internal and external systems, a BPI-based approach is required to address the coordination among many types of systems, and Web Services should be one of several options available to implement the integration among them.
BPEL has emerged as a standard to address BPI requirements. BPEL is a language that allows business analysts to consistently define business processes across companies. Because BPEL is based on XML standards, it ensures interoperability when integrating with other systems. BPEL promises to help coordinate integration efforts with customers, partners and vendors while making incremental changes to business processes easier to implement. However, despite the emergence of BPEL and SOA, many organizations are still reluctant to entirely abandon their legacy systems due to the expense in implementing different business methods.
Considering the limitations of legacy systems, it is clear that there is a need for an inexpensive method for converting existing legacy systems into a BPEL model supporting SOA capabilities.